home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 10631 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.4 KB
  1. Path: in2.uu.net!interaccess!usenet
  2. From: brianmcg@interaccess.com (Brian V. McGroarty)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: BoundsChecker and fgets fmalloc problems
  5. Date: 19 Mar 1996 01:38:20 GMT
  6. Organization: Internet Squire
  7. Message-ID: <4il36c$ltf@nntp.interaccess.com>
  8. References: <4ikfds$h8c@nnrp1.news.primenet.com>
  9. Reply-To: brianmcg@interaccess.com
  10. NNTP-Posting-Host: d48-isdn.nhe.interaccess.com
  11. X-Newsreader: Internet Squire 1.20
  12.  
  13. I haven't used Bounds Checker, but my guess would be that you might not be
  14. closing the file after reading from it.  I would suspect that some IO
  15. libraries don't create memory buffers until data is actually read from a
  16. file.  If a buffer is being created at this point, the memory might not be
  17. freed by the library if you don't explicitly close the file.
  18.  
  19.  
  20. Brian Gregory wrote:
  21. >I am using Bounds Checker v2.5, and am having a problem finding a
  22. >memory leak it is reporting...
  23.  
  24. >Example:
  25.  
  26. >fgets( szBuf, 799, fpIn );
  27.  
  28. >szBuf is an 800 character buffer (pre-sized array)
  29. >fpIn IS a valid pointer
  30. >no memory is corrupt before the fgets line
  31. >The application is a windows app, written in straight C with a large
  32. >memory model.
  33.  
  34. >The problem is Boundschecker consistently reports memory leaks for the
  35. >larger buffer size mallocs contained WITHIN the fgets function...
  36.  
  37.  
  38.  
  39.  
  40. ---
  41. Brian Valters McGroarty -- brianmcg@bix.com
  42. phone/fax (847) 439-7714
  43.  
  44.  
  45.  
  46.